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REMARKS/A RG UMENTS 

i 

In light of the remarks to follow, reconsideration and allowance of this application 
are requested. 

Claims 1-2, 5-9, and 12-14 have been rejected under 35 U.S.C. § 102(e) as being 
anticipated by Apte et al. U.S. Patent No. 6,269,373 (Apte et al.) and the claims 3-4 and 
10-11 have been rejected under 35 U.S.C. § 103(a) as being unpatentable over Apte et al. 
and further in view of U.S. Published Application No. 2002/0147696 (Acker et al.). 
Applicants respectfully traverse these rejections. 

Applicants submit that Apte et al. and Acker et al. are not prior art under 35 
U.S.C. § 102 and the § 102 and §103 rejections in Paper Nos. 5 and 8 based on Apte et al. 
and Acker et al. are improper and should be withdrawn. As stated in the Declaration filed 
on April 19, 2004, applicants respectfully submit that well prior to the February 26, 1999 
filing date of the Apte et al. patent (and well prior to the August 12, 1999 filing date of 
the Acker et al. published application), the present invention was conceived and reduced 
to practice. Both the Apte et al. patent and Acker et al. published application are 
therefore inapplicable as § 102 prior art and a reference that does not qualify as prior art 
under § 102 cannot be basis of a rejection under § 102 and §103. Applicant therefore 
respectfully request that rejections based on allegedly anticipation by Apte et al. and/or 
obviousness over the combination of Apte et al patent and Acker et al. published 
application be reconsidered and withdrawn. 

The Examiner alleges that the evidence submitted with the Declaration is 
insufficient to establish a conception of the invention of Apte et al. Applicant 
respectfully directs the Examiner attention to Exhibit B which includes a sample source 
code for SmartHandle.java, including the java.util.Comparable interface and delegation 
to a SmartKey for comparing attributes associated with the primary key to permit two 
EJB Handles to be compared without instantiating the corresponding Entity EJB Objects. 
Accordingly, Applicants respectfully submits that the evidence submitted with 
Declaration filed on April 19, 2004 is sufficient to establish a conception of the invention 
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prior to'the effective date of Apte et al. 

Moreover, contrary to the Examiner's assertion, Apte et al. independently or in 
combination with Acker et al. does not teach or suggest the present invention recited in 
claims 1 and 8. Apte et al. relates to a method for persisting a container-managed server 
object or bean in a distributed data processing system. Acker et al. relates to a system 
and method for improving name service behavior in a object-oriented programming 
environment, i.e., name service scoping behavior. Only the present invention teaches or 
suggests a SmartHandle which extends the capabilities of the EJB Handle, such as 
enabling part comparison of two EJB Handles without instantiating the actual EJB object, 
thereby advantageously enabling the present invention to order a list of SmartHandles 
without accessing the remote objects that they refer to (i.e., actual EJB objects). 

The Examiner incorrectly alleges that Apte et al. teaches the step of "maintaining 
an instance of a SmartKey that describes said primary key for a database column to 
which an Entity EJB object is mapped," as required in claim 1 and similarly in claim 8. 
In fact, col. 16, lines 57-65 and col. 17, lines 21-28 in Apte et al., cited by the Examiner, 
merely recite that " a container implemented on top of an RDBMS may manage 
persistence by storing each bean's data as a row in a table/' Whereas the present 
invention teaches that the instance of a SmartKey that describes the primary key to be 
maintained in a database column to which an Entity EJB object is mapped. This 
advantageously allows the SmartKeys and the SmartHandles that contain them to be 
easily compared and stored in ordered lists. 

Additionally, the Examiner incorrectly alleges that Apte et al. teaches the step of 
"maintaining an Entity EJB object relationship thorough a combination of a proxy 
pattern, an EJB Handle, and a primary key of the EJB Handle," as required in claim 1 and 
similarly in claim 8. In fact, col. 16, lines 40-52 in Apte et al., cited by the Examiner, 
merely describes that "An entity bean can be created in two ways ..." Applicants are 
puzzled as to how "creation of an entity bean" is equivalent to "maintaining an Entity 
EJB object relationship." 

Further, the Examiner incorrectly alleges that the Apte et al. teaches the step of 
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"storing EJB Home class from which an Entity EJB was generated and from which said 
Entity EJB can be re-instantiated," as required in claim 1 and similarly in claim 8. In 
fact, col. 16, lines 53-56 in Apte et al., cited by the Examiner, merely recites that "the 
bean is entirely responsible for storing and retrieving its instance data." However, 
applicants respectfully submits that one of ordinary skill in the art would not equate the 
step storing of its instance data by the bean to the step of "storing EJB Home class from 
which an Entity EJB was generated and from which said EJB can be re-instantiated," as 
called for in claim 1 (similarly in claim 8). 

Applicants respectfully that the Examiner cannot contradict the clear teaching or 
change the principle of operation of the principal reference. "If the proposed 
modification or combination of the prior art would change the principle of operation of 
the prior art invention being modified, then the teachings of the reference are not 
sufficient to render the claims prima facie obvious." (MPEP § 2143.01 citing In re 
Gordon , 733 F.2d 900, 221 USPQ 1125 (Fed. Cir. 1984) and In re Ratti , 270 F.2d 810, 
123 USPQ 349 (CCPA 1959)). 

In view of the foregoing differences, it is respectfully submitted that Apte et al. 
does not anticipate nor render obvious the invention as recited in claims 1 and 8, 
therefore, claims 1 and 8 are patentably distinct over this prior art. It is requested the 
rejection of claims 1 and 8 under 35 U.S.C. § 102(e) be withdrawn. 

Since claims 2, 5-7, 9 and 12-14 depend from claims 1 and 8, respectively, the 
foregoing discussion of claims 1 and 8 is equally applicable to claims 2, 5-7, 9 and 12-14 
and is believed to obviate the rejection of claims 2, 5-7, 9 and 12-14. 

In addition, it should be noted that claim 2 (and similarly claim 9) recites the step 
of "instantiating said Entity EJB object associated with said SmartHandle with a single 
method invocation." Apte et al. neither teaches or suggests such instantiating step. In 
fact, col. 16, lines 10-17 in Apte et al., cited by the Examiner, merely describe "stateless 
session beans" and is not even remotely related to an Entity Bean. 

Claim 5 (and similarly claim 12) defines that "said SmartKey includes said 
primary key of said EJB Handle, thereby providing portability to said Entity EJB object." 
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Apte et'al. neither teaches or suggests such SmartKey. In fact, col. 8, lines 58-67 in Apte 
et al., cited by the Examiner, merely describes that Remote Method Invocation depends 
on many features of Java-object serialization, portable, downloadable object 
implementations. 

Claim 6 (and similarly claim 13) recites the step of "assigning each attribute of 
said Entity EJB object and said SmartKey to a separate column within a relational 
database table, thereby permitting the SmartHandle to be mapped to a multi-column 
relational database table." Apte et'al. neither teaches or suggests such assigning step 
where each attribute of the Entity EJB object and the SmartKey are assigned to a separate 
column. In fact, col. 16, lines 57-61 in Apte et al., cited by the Examiner, merely 
describes that "a container implemented on top of an RDBMS may manage persistence 
by storing each bean's data as a row in. a table." 

Claim 7 (and similarly claim 14) defines that SmartHandle includes at least 
attributes HomeClassName, KeyClassName and HomeName. Apte et al. does not teach 
or suggest such SmartHandle. 

As stated herein, Acker et al. relates to process and system for providing name 
service scoping behavior. But Acker is not suggestive of the steps of maintaining an 
Entity EJB object relationship, storing EJB Home class from which an Entity EJB was 
generated and from which it can be re-instantiated, and maintaining an instance of a 
SmartKey that describes the primary key for a database column which an Entity EJB 
object is mapped, as required in claim 1 and similarly in claim 8. These, of course, are 
features recited by independent claims 1 and 8 (and thus are included in dependent claims 
3-4 and 10-1 1) and not found in Apte et al. and Acker et al. Hence, the addition of Acker 
et al. does not cure the aforenoted deficiencies of Apte et al. 

In view of the foregoing differences, it is respectfully submitted that the 
combination of Apte et al. and Acker etal. does not render obvious claims 3-4 and 10-11. 
It is requested the rejection of claims 3-4 and 10-1 1 under 35 U.S.C. §103 be withdrawn. 

In addition, the Examiner alleges that Apte et al. teaches the steps of using 
reflection to obtain an ejbFindByPrimaryKey method and invoking the 
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ejbFindByPrimaryKey method with the SmartKey, but dos not teach the step of loading 
the EJB Home class using JNDI, as required in claim 3 (and similarly in claim 10). To 
cure this deficiency in Apte et al., the Examiner turns to Acker et al. However, contrary 
to the Examiner's assertion, Apte et al. does not even teach or suggest the steps of using 
reflection and invoking the ejbFindByPrimaryKey recited in claim 4 (and similarly in 
claim 10). In fact, col. 7, lines 31-38 and col. 6, lines 58-67 in Apte et al., cited by the 
Examiner, merely describes that EJB can be invoked by clients or EJBs residing in one 
machine can be remotely invoked from another machine. Additionally, Apte et al. clearly 
states that "one cannot persist EJBs by storing their Home Name and Key Value" (col. 2, 
lines 36-37). Further, contrary to the Examiner's assertion, Acker et al. does not teach or 
suggest locating the EJB Home class using JNDI, as required in claim 3. In fact, 
paragraph [0006] in Acker et al., cited by the Examiner, merely describes that JNDI can 
be used to find object in the name space. Therefore, the combination of Apte et al. and 
Acker et al. does not teach or suggest the steps recited in claim 3 (and similarly in claim 
10). 

Furthermore, the Examiner alleges that Acker et al. teaches the steps of 
implementing java.util.Comparable interface and delegating to a SmartKey class that 
performs field-by- field comparison of attributes associated with the primary key, thereby 
permitting two EJB Handles to be compared without instantiating the corresponding 
Entity EJB Objects. However, contrary to the Examiner's assertion, Acker et al. does 
teach or suggest such implementing and delegating steps recited in claim 4 (and similarly 
in claim 11). In fact, paragraphs [0045] and [0038] in Acker et al., cited by the 
Examiner, merely describes states that "it is desirable to allow rebinding of the EJBs in 
an appropriate scope of the namespace without having to change the EJB deployment 
data and redeploying" and "a delegation model could just as easily be used, or the scoped 
initial context factory could completely implement the 
javx.naming.spi.InitialContextFactory Interface." JNDI can be used to find object in the 
name space. It is appreciated that one of ordinary skill in the art would not associate the 
delegation model of Acker et al. to scope the name tree as being remotely related to 
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delegating to a SmartKey class to perform field^by-field comparison to EJB Handles 
without instantiating the corresponding Entity EJB Objects, as required in claim 4 
(similarly in claim 111). Therefore, the combination of Apte et al. and Acker et al. does 
not teach or suggest the steps recited in claim 4 (and similarly in claim 11). 

Statements appearing above in respect to the disclosures in the cited references 
represent the present opinions of the applicants' undersigned attorney and, in the event 
that the Examiner disagrees with any of such opinions, it is respectfully requested that the 
Examiner specifically indicate those portions of the reference providing the basis for a 
contrary view. 

In view of the above, each of the presently pending claims in this application is 

believed to be in immediate condition for allowance. Accordingly, the Examiner is 

respectfully requested to pass this application to issue. 

* * * 

The Commissioner is hereby authorized to deduct any fee or credit any 
overpayment to Deposit Account No. 50-0624, under Order No. NY-THEOR 201.1 
(09907976) from which the undersigned is authorized to draw. 

Respectfully submitted, 




C. Andrew Im 

Registration No.: 40,657 

FULBRIGHT & JAWORSKI L.L.P. 

666 Fifth Avenue 

New York, New York 10103 

(212) 318-3000 

(212)318-3400 (Fax) 

Attorneys for Applicant 
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